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This  report  summarizes  the  options  available  to  BGS  Systems  with  respect 
to  building  an  interface  between  the  ,'SL  facility  (developed  by  the  ISDOS 
group  at  the  University  of  Michigan)  and  POD.  The  choices  span  a  range  in 
sophistication,  user  appeal,  and  amount  of  effort  involved.  The 
appropriate  choice  should  probably  be  based  on  the  extent  to  which  the  more 
sophisticated  options  could  be  expected  to  make  POD  and  PSL/PSA  easier  to 
use  together  and  on  the  demands  of  the  POD  user  community.  An  appendix 
describes  a  manual  procedure  for  converting  PSL  system  descriptions  to  a 
POD  SDF  and  describes  PSA  reports  that  are  useful  aids  for  performing  this 
translation. 


!  2  PSL/PSA  and  SEM 
+ - - - — _ _ _ _ _ 
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An  important  issue  is  that  there  are  really  two  ISDOS  products  that  we 
can  interface  to: 

*  PSL/PSA  is  the  older  product  with  an  established  user  base 
(including  some  current  and  potential  POD  users  at  NSWC,  NUSC, 

NOSC ,  and  NAVAIR). 

*  SEM  is  a  newer  facility  with  very  few  users,  but  greater 
flexibility  and  a  good  deal  of  future  potential. 


An  overview  of  how  these  systems  function  is  shown  in  Figures  1  (PSL/PSA) 
and  2  (SEM) . 

PSL/PSA  consists  of  a  Problem  Statement  Language  (PSL)  and  a  Problem 
Statement  Analyzer  (PSA).  A  description  of  a  system,  written  in  PSL,  is 
fed  into  PSA,  which  then  produces  a  number  of  reports  describing  the 
system.  The  reports  to  be  produced  are  specified  using  PSA  commands  and 
directives.  This  is  illustrated  in  figure  1. 
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An  important  issue  is  that  there  are  really  two  ISDOS  products  that  we 
can  interface  to: 

*  PSL/PSA  is  the  older  product  with  an  established  user  base 
(including  some  current  and  potential  POD  users  at  NSWC,  NUSC, 

NOSC,  and  NAVAIR). 

*  SEM  is  a  newer  facility  with  very  few  users,  but  greater 
flexibility  and  a  good  deal  of  future  potential. 


An  overview  of  how  these  systems  function  is  shown  in  Figures  1  (PSL/PSA) 
and  2  (SEM). 

PSL/PSA  consists  of  a  Problem  Statement  Language  (PSL)  and  a  Problem 
Statement  Analyzer  (PSA).  A  description  of  a  system,  written  in  PSL,  is 
fed  into  PSA,  which  then  produces  a  number  of  reports  describing  the 
system.  The  reports  to  be  produced  are  specified  using  PSA  commands  and 
directives.  This  is  illustrated  in  figure  1. 
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USED  FOR: 

*  DOCUMENTATION  OF  INTERFACES 

*  DETAILED  DESCRIPTION  OF  RELATIONSHIPS  AMONG  DATA  ITEMS 
AND  BETWEEN  DATA  AND  PROGRAMS 

*  CAN  CHECK  CONSISTENCY  AND  COMPLETENESS  OF  SYSTEM  SPECIFICATION 

FIGURE  l:  Problem  Specification  Language/Problem  Statement  Analyzer  (PSL/PSA) 


The  System  Encyclopedia  Manager  (SEM)  is  a  more  elaborate  facility  that 
includes  three  subsystems  -  a  Database  Manager,  the  Generalized  Analyzer 
(GA)  and  a  Query  Facility  -  as  well  as  a  separate  front  end,  META,  for 
describing  system  definition  languages.  A  language,  such  as  PSL  or  POD,  is 
described  to  META  in  its  metalanguage.  META  processes  this  language 
definition  and  produces 

*  an  internal  database  used  by  SEM 

*  a  language  reference  manual 

*  various  diagnostic  checks  and  reports  about  the  language. 
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A  user  enters  a  system  description  to  SEM  in  the  appropriate  description 
language,  in  this  case  either  PSL  or  a  POD  SDF.  SEM  references  its 
language  definition  table  database  to  interpret  this  description  and  enter 
it  into  a  database  containing  information  about  the  system.  A  database 
management  subsystem  is  used  as  the  interface  to  the  database  of  system 
descriptions.  A  report  facility,  the  Generalized  Analyzer,  and  an 
interactive  Query  Facility  are  available  to  analyze  the  database  and 
produce  reports  and  validation  checks  on  the  system.  This  is  illustrated 
in  Figure  2. 


FIGURE  2: 


The  System  Encyclopedia  Manager  (SEM) 
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FIGURE  3:  Architecture  of  a  SEM-POD  Interface 
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SEM  is  more  general  than  PSL/PSA  and,  thus,  easier  to  interface  to  other 
systems,  but  this  generality  reduces  the  ability  of  the  Generalized 
Analyzer  to  generate  specific  reports  -  so  certain  PSA  reports  are  not 
currently  available  under  SEM. 


+ - - - - — - 

|  3  Architecture  of  a  SEM  -  POD  Interface 
+ - - - 


An  overview  of  how  POD  and  PSL  would  interact  using  SEM  is  shown  in 
Figure  3-  In  the  figure  definitions  of  PSL  and  POD  are  fed  into  META, 
which  produces  various  reports  about  each  of  them  and  enters  the  language 
definitions  into  the  language  definition  database.  A  PSL  description  of  a 
system  and  a  POD  SDF  are  input  to  SEM.  SEM  uses  the  language  definition 
database  to  interpret  the  system  descriptions  and  enters  the  processed 
system  descriptions  into  its  system  description  database.  Reports  based  on 
these  descriptions  can  then  be  produced  using  the  Generalyzed  Analyzer  and 
validation  checks  can  be  done  with  the  Query  Facility.  The  POD  SDF  can  be 
input  to  xOD  to  analyze  projected  system  performance  and  the  results  fed 
back  to  the  database  using  the  Project  History  Database  (PHDB)  facility  and 
a  SEM  interface  yet  to  be  specified.  This  is  perhaps  the  cleanest  and  most 
flexible  approach  to  interfacing  the  two  systems. 


- - + 
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Three  alternative  approaches  that  could  interface  PSL/PSA  and  POD 
without  going  through  SEM  are  illustrated  in  Figure  4.  The  first  and 
simplest  approach  (option  1)  involves  taking  PSA  output  reports  and  using 
the  information  contained  in  them  to  manually  build  a  POD  SDF.  The  main 
PSA  reports  that  could  be  useful  for  doing  this  are  summarized  and 
illustrated  in  Appendix  A. 

Automatically  generating  a  POD  SDF  from  PSA  output  reports  would  not  be 
feasible  since  the  precise  formats  are  volatile  (subject  to  change)  and 
contain  large  numbers  of  extraneous  characters  included  for  aesthetics  and 
formatting  rather  than  informational  content.  In  addition,  the  information 
needed  by  POD  is  divided  among  PS t  reports  and  merging  these  into  a  single 
SDF  could  be  cumbersome  In  add  :  '  on,  the  operational  procedures  would  be 
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FIGURE  A:  BGS  Ootions  for  Tnterfacinc  PSI,  rn  POD 
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more  complex  than  in  options  2  and  3» 

Option  2  involves  automatically  generating  a  POD  SDK  from  information 
contained  in  the  PSA  system  description  database.  This  is  a  promising 
approach  but  would  involve  getting  access  to  the  PSA  internal  formats  and 
interfaces  and  would  thus  involve  a  joint  effort  by  BGS  Systems  and  ISDOS. 
In  this  case  u  POD  SDK  file  would  be  generated  s  a  special  PSA  report. 

This  approach  would  have  a  natural  extension  to  a  SEM  interface  if  the  SDF 
report  was  generated  using  the  Generalized  Analyzer  instead  of  PSA.  ISDOS 
seems  used  to  making  arrangements  (providing  the  necessary  support)  for  the 
generation  of  such  reports  (which  it  calls  "bridges")  in  the  SEM 
environment . 

Option  3  involves  directly  translating  a  PSL  system  description  into  a 
POD  SDF.  This  involves  building  a  translator  that  was  independent  of  PSA 
and  the  Generalized  Analyzer.  If  a  SEM  interface  was  used,  its  Query 
Facility  could  be  used  to  compare  the  PSA  and  SDF  description  and  check  for 
consistency  and  completeness.  This  option  is  probably  less  desirable  than 
option  2  since  system  descriptions  can  sometimes  be  entered  piecemeal  so 
that  no  single  PSL  description  would  contain  a  complete  and  current  view  of 
the  system.  By  contrast,  the  PSA  database  should  always  contain  the 
complete  current  specification  for  the  system. 

Both  options  2  and  3  would  benefit  substantially  from  an  extension  of 
PSL  that  would  encourage  the  user  to  provide  more  performance  related 
information  and  to  enter  this  data  in  a  PSL  description  in  a  standardized 
way.  Some  of  the  issues  involved  in  doing  this  are  discussed  in  [ij. 

Under  options  2  and  3,  the  resulting  SDF  would  be  more  complete  and  would 
require  less  manual  manipulation,  tuning,  and  filling  in  of  missing  data. 
Even  under  option  1 ,  users  would  become  more  conscious  of  performance 
related  factors  at  an  earlier  stage  of  system  specification.  This  would 
both  facilitate  the  manual  creation  of  an  SDF  and  probably  lead  them  to  the 
design  of  better  p‘- '•forming  systems. 

Finally  we  come  to  the  issue  of  feedback  of  the  results  of  POD  analysis 
into  the  PSL  reporting  facilities.  This  could  probably  be  done  most  easily 
via  SEM  using  the  TOD  Project  History  Data  Base  (PHDB)  facilities.  Formats 
would  be  defined  to  SEM  using  META.  The  PHDB  data  would  be  entered  to  the 
system  description  by  using  SEM.  The  generalized  analyzer  and  query 
facility  could  then  be  used  to  report  on  POD  results  in  a  way  analogous  to 
how  SAS  is  being  used  currently.  It  is  likely,  however,  that  we  would 
choose  to  define  more  highly  structured  reports  and  data  formats  to  be  used 
with  this  type  of  system  than  we  are  currently  doing  using  SAS.  An 
alternative  approach  that  should  also  be  considered  is  to  have  POD  generate 
PSL  specifications  of  performance  related  quantities  as  a  special  report 
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option.  One  possible  implementation  of  thi3  would  be  to  use  the  PHDB 
external  interface  to  write  out  the  appropriate  performance  related 
information  to  an  external  file  which  would  then  be  processed  by  a  report 
facility  to  generate  a  PSL  description. 


+ - + 

!  5  Conclusion  ! 

+ - + 


In  summary,  we  have  described  the  main  options  available  for  interfacing 
POD  and  PSL/PSA/SEM.  A  direct  PSL  -  SDF  translator  would  be  an  appropriate 
tool  to  implement  if  only  limited  ISDOS  support  can  be  expected  and  a  PSL 
interface  is  expected  to  get  substantial  use.  A  new  PSA  or  SEM/GA  report 
from  the  system  description  database  would  be  a  preferable  alternative  if 
substantial  ISDOS  cooperation  is  available  or  a  joint  effort  is  undertaken. 
This  would  also  provide  the  most  robust  interface  since  the  database  system 
description  is  generally  more  complete  and  current  than  any  single  PSL 
description.  A  manual  conversion  would  be  the  best  approach  if  only 
limited  joint  use  is  expected  and/or  BGS  wishes  to  limit  the  amount  of 
resources  it  devotes  to  this  project.  In  any  case,  extension  of  PSL  to 
include  more  performance  oriented  information  using  POD  terminology  would 
be  beneficial 

*  by  making  users  more  aware  of  performance  at  an  earlier  stage  in 
system  specification 

*  by  getting  them  used  to  the  POD  operational  terminology  and  way  of 
looking  at  performance 

*  and  by  facilitating  whatever  PSL  to  POD  conversion  (manual  or 
automatic)  might  be  undertaken. 
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1  6  PSA  Repoits  Useful  for  Manually  Producing  an  SDF  ! 

+ - + 


The  most  useful  PSA  reports  that  could  serve  as  aids  in  producing  a  POD 
SDF  file  are: 

*  the  structure  report 

*  the  picture  report 

*  the  process  chain  report 

*  the  frequency  report 

*  the  resource  consumption  report 

*  system  size  and  volume  reports 


These  reports  are  described  and  illustrated  in  this  appendix. 

The  PSA  Structure  Report  gives  a  breakdown  of  the  module  calling 
hierarchy  of  a  system.  This  is  useful  in  producing  a  skeleton  of  the 
module  specification  section  of  the  SDF.  A  typical  structure  report  is 
shown  in  Figure  A-1  . 

The  PSA  Picture  Report  shows  the  interfaces  of  a  system  including  the 
processes  and  events  that  trigger  and  invoke  a  particular  process  (control 
interface)  and  the  inputs  used  and  outputs  generated  by  the  process.  This 
gives  a  visual  picture  of  the  data  and  control  flow  through  a  system  and 
the  files  that  may  be  used  by  a  module.  A  typical  picture  report  is  shown 
in  Figure  A-2. 

The  PSA  Process  Chain  Report  shows  the  control  flow  through  a  system  in 
terms  of  which  events/ processes  trigger  or  call  which  other  events  and 
processes.  It  summarizes  the  control  flow  through  a  system.  A  Process 
chain  report  is  shown  in  Figure  A-3 • 

The  PSA  Frequency  Report  relates  system  inputs  and  process  invocation  to 
the  frequency  with  which  they  occur.  This  frequency  may  be  dependent  on  a 
system  parameter.  This  report  is  useful  in  determining  workload  arrival 
rate,  file  access,  and  numbe”  of  times  a  module  call  will  be  invoked  and 
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how  many  iterations  will  be  made  through  a  loop.  A  Frequency  report  is 
shown  in  Figure  A -4. 

The  Resource  Consumption  Analysis  Report  is  available  with  release  5.1« 
of  PSL/PSA  and  summarizes  specific  resource  utilization  information.  Note 
that  the  information  is  not  available  in  system  descriptions  based  on 
earlier  releases  of  PSL/PSA  (including  the  one  in  use  at  NSWC) .  The  report 
contains  the  information  needed  to  generate  the  server  usage  statements  in 
the  SDF  module  specification  sections  and,  where  available,  is  among  the 
most  useful  PSA  reports.  Because  of  its  potential  usefulness,  a  more 
detailed  description  is  given  below. 

The  Resource  Consumption  Analysis  report  of  PSA  presents  processors' 
consumption  of  resources  in  performing  the  specified  process  and  its 
component  processes.  The  analyzer  performs  a  walk  of  the  SUBPARTS_UTI LIZES 
network  which  starts  at  the  specified  PROCESS  name  and  extends  to  the 
specified  number  of  levels.  The  resource  consumption  and  frequency 
information  is  computed  for  each  visit  to  each  process  in  the  structure. 
Since  a  process  may  be  visited  many  times,  its  resource  consumption  may  be 
computed  many  times  as  well.  Depending  upon  the  viewpoints,  two  formats  - 
BYPROCESSOR  and  BYRESOURCE  -  may  be  used  in  PSA  to  provide  resource 
consumption  status  about  each  PROCESS.  This  is  illustrated  by  the 
following  example: 

ROOT  PROCESS:  UPDATE_RECORD 

PROCESSOR  CENTRAL_PF OCESSOR  IS  INVOKED  800  TIMES  PER  HOUR 

RESOURCE  CONSUMED  AMOUNT  CONSUMED  MEASURED  IN 
CPUJTIME  219.5  MSEC 

PROCESSOR  DISI_A  IS  INVOKED  800  TIMES  PER  HOUR 

RESOURCE  CONSUMED  AMOUNT  CONSUMED  MEASURED  IN 
nSK_A_TIME  105.0  MSEC 

The  above  report  is  presented  in  BYPROCESSOR  format. 
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If  BYRESOURCE  format  is  used,  the  report  may  appear  as  below: 
ROOT  PROCESS:  UPDATE  RECORD 


RESOURCE  CPU -TIME  MEASURED  IN  MSEC 

PROCESSOR  CONSUMING  FREQUENCY  AMOUNT  CONSUMED 
C  ENTRAL_PR  OC  ES  SOR  800/HOUR  215.5 

RESOURCE  DISK  A  TIME  MEASURED  IN  MSEC 


PROCESSOR  CONSUMING  FREQUENCY  AMOUNT  CONSUMED 

DISK  A  800/HOUR  103.0 


System  Size  and  Volume  Reports  summarize  the  information  related  to  size 
and  volume  that  is  usually  entered  as  system  parameters  to  PSL/PSA.  These 
reports  are  only  available  from  release  5.1  and  later  releases  of  PSL/PSA. 
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Appendix  B 


+ - + 

1  7  Cookbook  Approach  to  Building  a  POD  Model  from  PSA  Reports  i 
+ - - 


In  the  interval  until  automated  tools  become  available,  PSL/PSA  users 
who  wish  to  build  a  POD  model  can  make  use  of  a  number  of  PSA  reports  that 
provide  relevant  information  about  the  system  to  be  modeled.  In  this  way, 
PSL/PSA  users  can  capture  the  information  they  have  already  collected  about 
their  system  in  a  FSA  database  and  incorporate  that  information  into  the 
POD  model.  As  an  aid  to  doing  this  the  following  six  step  procedure  is 
suggested . 


1.  Identify  modules  and  calling  relationships  using  the  PSL 
structure  report. 

2.  Identify  file  usage  and  other  I/O  using  the  PSL  picture  report. 

3.  Identify  workloads  and  their  relationship  to  modules  using  the 
PSL  process  chain  report. 

4.  Incorporate  looping  and  case  distribution  using  the  PSL  process 
chain  report. 

5.  Determine  workload,  looping,  and  file  access  rates  using  the  PSL 
frequency  report. 

6.  Incorporate  actual  resource  demands  using  the  PSL  resource 
consumption  analysis  report. 


The  diagrams  on  the  following  pages  show  how  the  PSL/PSA  to  POD  mod^l 
transformation  can  be  made  using  a  very  simple  system  as  an  example. 

1.  The  PSL  structure  report  for  processes  shows  the  breakdown  of 
processes  (modules)  by  the  subprocesses  (modules)  that  it  calls.  This 
hierarchical  view  of  system  structure  can  be  translated  into  POD  calling 
relationships.  This  is  illustrated  in  Figure  1. 

2.  The  PSA  Picture  Report  links  processes  (modules)  to  the  inputs  and 
outputs  they  interface  wi th.  This  information  can  be  used  to  determine 
system  file  access  patterns.  This  is  shown  in  Figure  2. 

3*  The  process  chain  report  is  then  used  to  associate  processes 
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Figure  1:  Identifying  the  Tree  Structure  Calling  Hierarchy 


1.  PSL  STRUCTURE  REPORT 

IDENTIFIES  MODULE  TREE  STRUCTURE  CALLING  HIERARCHY 


1.  MSG. HANDLING 
2  READ 

3  DECRYPT 
2  UPDATE 

2  FORWARD 


MODULE  I1SG_HANDLING 
CALL  READ 

CALL  UPDATE 
CALL  FORWARD 


MODULE  READ 
CALL  DECRYPT 
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(modules)  with  the  events  (workloads)  that  cause  them  to  be  invoked.  This 
in  illustrated  in  Figure 

4.  The  Process  Chain  Report  also  contains  information  that  can  be  used 
to  introduce  loop  and  case  structures  into  the  POD  model.  Case  structures 
are  introduced  when  a  process  (module)  invokes  other  processes  (calls 
submodules  or  invokes  other  processing  subsequences)  with  probabilities 
dependent  on  some  external  condition(s)  being  true.  Looping  is  introduced 
when  the  frequency  of  invocation  of  some  processing  subsequence  is 
dependent  on  a  condition  or  parameter.  This  is  illustrated  in  Figure  4. 

5.  The  Frequency  Report  is  used  to  associate  actual  values  or  formal 
parameters  to  the  dummy  parameters  previously  filled  in  from  information  in 
the  Process  Chain  and  Picture  Reports.  In  this  way  the  workload  arrival 
rate,  degree  of  looping,  and  number  of  file  accesses  can  be  filled  in. 

This  is  illustrated  iu  Figure  5* 

o.  Finally  the  actual  resource  consumption  estimates  for  the  POD  model 
are  filled  in.  This  can  be  gotten  from  version  5*1  and  later  releases  of 
PSL/PSA  using  the  Resource  Consumption  Analysis  Report.  In  earlier 
releases  this  information  would  have  to  be  collected  separately  (or 
included  in  the  PSL  description  as  a  comment  or  attribute  value  field  and 
gotten  from  a  report  showing  values  of  that  attribute). 

The  state  of  a  typical  POD  SDF  after  each  stage  of  this  process  is 
illustrated  Figures  B6A-B6G. 

Sample  printouts  of  the  PSA  Structure,  Picture,  Process  Chain  and 
Frequency  Reports  are  shown  in  Figures  A1-A4. 
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Figure  3:  Identifying  Workloads  and  +heir  Relationships  to 
Modules 


EVENT 

HERE 


EVENT 


MSG  ARR 


PROCESS 


MSG. HANDLING 


EVENT 


ELSEWHERE 


WORKLOAD  MS GAR R 


JOB_STREAM  =  HS G_H AND LING 


PROCESS 

UPDATE 


29  September  1981 


Figure  4:  Incorporating  Looping  and  Case  Distribution 


EVENT 


DESTINATION 
=  HERE 


MSGARR 


PROCESS 


MSG_HANDLING 


PROCESS 


UPDATE 

1 

PROCESS 

-  -  . . 

FORWARD 

READ 

I 

EVENT 


:  ENCRYPTED 

DECRYPT  PROCESS 


MODULE  HSGJANDLING 
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CALL  DECRYPT 
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Figure  5:  Determining  Workload,  Looping,  and  File  Access 
Rates 
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PROTOTYPICAL  MODULE  SPEC!  FI  CAT  I  Oti 


AFTER  STEP  2 

MODULF  MSGJANDLING 


CALL  READ 


CALL  UPDATE 


CALL  FORWARD 


END 


MODULE  READ 

|  EST  MSG  USAGE  =  II  READS 
CALL  DECRYPT 

|  EST  ERROR-FILE  USAGE  =  M  WRITES 
END 
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PROTOTYPICAL  WORKLOAD.  SPECIFICATION 
AFTER  STEP  3 

WORKLOAD  MSGARR 


JOB_STREAf1  =  MSGJIANDLING 
END 
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PROTOTYPICAL  MODULE  SPECIFICATION 
AFTER  STEP  4 


MODULE  MS6.HANDLING 
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EST  ERROR.FILE  USAGE  =  M  WRITES 
END 
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PROTOTYPICAL  MODULE  SPECIFICATION 
AFTER  STEP  5 


MODULE  HSGJANDLIKG 


CALL  READ 

TEST  DESTINATION 
CASE  'HERE' 

CALL  UPDATE 

CASE  'ELSEWHERE' 
CALL  FORWARD 
ENDTEST 


END 

MODULE  READ 

EST  MSG  USAGE  =  1  READS 
LOOP  PARMl  TIMES 
CALL  DECRYPT 
ENDLOOP 

EST  ERROR_FILE  USAGE  =  3  WRITES 
END 


FIGURE  B6-F. 


PROTOTYPICAL  WORKLOAD.  SPECIFICATION 
AFTER  STEP  5 

WORKLOAD  HSGARR 


I 


ARRI VAL_RATE  =  1000  /HR 


PROTOTYPh.AL 


•’0! 
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AFTER  STEP  6 


MODULE  MSG  ..HANDLING 

EST  CPU1  USAGE  =  300  MSEC 
CALL  READ 

TEST  DESTINATION 
CASE  'HERE' 

CALL  UPDATE 

lASL  'LLSLWIIL  RL' 
CALL  FORWARD 
END! EST 


END 


MULE  READ 

EST  MSG  USAGE  =  1  READ 

LOOP  PARIT1  TIMES 
CALL  DECRYPT 
ENDLfiQP 


EST  LliRORJ'lLE  USAGE 
L.ND 


I  IGURE  B()-G 
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